REMARKS 



No claims have been amended, added or cancelled. Claims 1-53 remain pending 
in the application. Reconsideration is requested in light of the following remarks. 

Section 103(a) Rejection : 

The Examiner rejected claims 1-53 under 35 U.S.C. § 103(a) as being 
unpatentable over Carlson et al. (U.S. Publication 2003/0056022) (hereinafter "Carlson") 
in view of "3 The Model- View-Controller Architecture" (hereinafter "3MVC"). 
Applicants respectfully traverse this rejection for at least the reasons presented below. 

Regarding claim 1, contrary to the Examiner's assertion, Carlson in view of MVC 
fails to teach or suggest a dynamic component generator configured to receive a new set 
of requirements for an application and generate a second dynamic component to replace 
the first dynamic component, wherein the second dynamic component is configured to 
function according to the new set of requirements. Carlson teaches configurable JAVA 
classes created as instances of a metaclass object that includes subclasses and interfaces 
that themselves include methods to alter attributes and methods of a configurable JAVA 
class. MVC teaches the decoupling of model, view and controller objects of an 
application. The Examiner cites passages of Carlson (col. 5:14-25) describing how 
Carlson's "invention allows the creation of new Java classes and the change of existing 
Java classes . . . new functionality can be introduced by configuring new classes rather 
than redevelopment." However, Carlson in view of MVC fails to teach or suggest a 
dynamic component generator configured to receive a new set of requirements, Carlson 
teaches a metaclass object that includes methods "to alter the attributes and methods of 
the Java class instance of the metaclass object" (Carlson, paragraph 0025). However, 
providing a system that includes methods to alter attributes and methods of a Java class 
instance is not the same as an application having a generator component that receives a 
set of requirements. Carlson does not mention any component of his system receiving a 
set of requirements. In fact, Carlson is completely silent about communicating 
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requirements. Carlson's system pertains only to a system in which a programmer may 
utilize Carlson's metaclass object, and specifically the metaclass object's method for 
altering attributes and methods, to modify configurable Java classes at runtime. 

In response the above arguments, the Examiner cites paragraphs [0037] and 
[0041] of Carlson. Paragraph [0037] of Carlson describes Carlson's Softype Interface 20 
and SofttypeBean 22. Carlson teaches that the Softype Interface 20 allows run-time 
configuration of the Softype instances and that the methods and attributes of the 
SofttypeBean 22 can be dynamically defined and altered. Properties and methods may be 
added to instances of SofttypeBean 22. Thus, paragraph [0037] describes the ability to 
dynamically alter properties and method of existing SofttypeBean instances, but makes 
no mention of a dynamic component generator configured to receive a new set of 
requirements for the application. Merely teaching that properties and methods of class 
and object instances can be altered does not teach or suggest anything about receiving a 
set of application requirements and generating a second dynamic component to replace 
the first dynamic component, wherein the second dynamic component is configured to 
function according to the new set of requirements. Paragraph [0041] of Carlson, also 
cited by the Examiner, describes that method and property definitions may be included in 
an XML file. Thus, as illustrated by the Examiner's cited passages, Carlson's system 
includes dynamically altering the properties and methods of existing object instantiations 
according to XML-based definitions of properties and methods. Method and property 
definitions are not the same as requirements for an application. Application requirements 
as recited in Applicants' claim 1, and definitions of class properties and methods as 
recited in Carlson, are two very different things, as would be well understood by anyone 
of ordinary skill in the art. Carlson's system does not deal with application requirements, 
but instead dynamically alters instantiated class objects according to predefined 
properties and methods. 

Carlson in view of MVC also fails to teach or suggest a dynamic component 
generator configured to generate a second dynamic component to replace the first 
dynamic component, where the second dynamic component is configured to function 
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according to the new set of requirements . The Examiner states that Carlson's system 
"allows the creation of new Java classes and the change of existing Java classes" and that 
in Carlson's system "new functionality can be introduced by configuring new classes". 
However, the Examiner does not show any passage of the cited art that teaches or 
suggests a component generator configured to generate a second dynamic component to 
replace the first dynamic component and configured to function according to the new set 
of requirements . Carlson does not describe anything in his system that is configured to 
generate a component configured to function according to a new set of requirements and 
to replace a first dynamic component. As noted above, merely providing methods to alter 
attributes and methods of Java classes does not imply a component configured to 
generate new components that function according to a set of requirements and replace 
another dynamic component. Carlson's altering of existing methods and properties of 
existing class and object instances clearly does not teach or suggest generating a new 
dynamic component to replace another dynamic component where the new dynamic 
component is configured to function according to a new set of requirements for the 
application. 

In his Response to Arguments, the Examiner cites paragraph [0036] of Carlson 
and refers to the fact that Carlson's Softype object includes a DynamicEntity that 
includes methods to add and remove directly contained properties and also to add and 
remove methods from a class object. The Examiner has cited portions of Carlson that 
describe the ability to modify properties and methods of existing classes and objects 
according to property and method definitions. As discussed above, property and method 
definitions are not new application requirements. The Examiner's cited passages do not 
describe generating a second dynamic component to replace a first dynamic component 
where the second dynamic component is configured to function according to a new set of 
requirements for the application. As described above, Carlson teaches altering existing 
properties and methods according to property and method definitions (Carlson, 
paragraphs [0035] and [0040-0042]), but nowhere does Carlson teach generating a 
second dynamic component to replace a first dynamic component where the second 
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dynamic component is configured to function according to a new set of requirements for 
the application. 

Furthermore, MVC, alone or in combination with Carlson, fails to teach or 
suggest anything about receiving a set of new application requirements or about 
generating a dynamic component configured to function according to the new set of 
application requirements and thus fails to overcome any of the above noted deficiencies 
of Carlson. The Examiner, in the Response to Arguments, contends that Carlson's 
Softype meta-class object corresponds to a dynamic component generator and again cites 
paragraph [0037] of Carlson. However, as noted above, paragraph [0037] describes the 
ability to dynamically alter properties and method of existing SofttypeBean instances, but 
makes no mention, however, of a dynamic component generator configured to generate a 
dynamic component configured to function according to a new set of requirements for 
the application. Instead, as noted above, Carlson teaches using property and method 
definitions to alter the properties and methods of existing classes and objects. 

Thus, for at least the reasons presented above, the rejection of claim 1 is not 
supported by the cited prior art and removal thereof is respectfully requested. Similar 
remarks as those above regarding claim 1 also apply to claims 14, 27 and 4L 

Applicant also asserts that numerous ones of the dependent claims recite further 
distinctions over the cited art. However, since the rejection has been shown to be 
unsupported for the independent claims, a further discussion of the dependent claims is 
not necessary at this time. 
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CONCLUSION 



Applicants submit the application is in condition for allowance, and notice to that 
effect is respectfully requested. 

If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5681- 
08800/RCK. 

Also enclosed herewith are the following items: 
E<] Return Receipt Postcard 
I I Petition for Extension of Time 
O Notice of Change of Address 
□ Other: 



Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8850 

Date: September 9. 2005 



10/092,168 (5681-08800/P7202) 6 Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C. 



Respectfully submitted, 




Robert C. Kowert 
Reg. No. 39,255 • 

ATTORNEY FOR APPLICANT(S) 



